Troubleshooting Schema Synchronization Issues Notes
Schema synchronization problems often manifest themselves in the following symptoms:
- You can’t create objects
- You can’t replicate objects
- Objects are inconsistent
- You receive 603, 604, 608, or 609 errors
Fix Schema Synchronization Problems
To fix eDirectory schema synchronization problems you can use iManager/eDirectory Maintenance Utilities/Schema Maintenance, or you can use the Global Options Operations menu in DSREPAIR.
Using the –A option will display additional menu options.
Option |
Use to |
Import Remote Schema |
Update the schema on the local server to match that of another tree. Useful for preparing for a merge, but it is an all-or-nothing option, so be careful. |
Reset Local Schema |
Reset each local schema and schedule the option Receive All Schema from the Replica to the Local Replica. This option will not run if the local server has the master of [Root]. |
Post NetWare 5 Schema Update |
Extend the eDirectory schema so that it is compatible with schema changes in eDirectory. You would use this option on a server holding replica of the [Root] partition prior to installing eDirectory for the first time or when updating. |
Optional Schema Enhancements |
Extend the schema with containment and other enhancements. |
Update All Server’s Schema (NetWare 4 versions) |
Update the schema on all servers in the eDirectory tree. |
Update the Root Server Only (NetWare 4 versions) |
Update the schema on the server that contains the master replica of the [Root] partition. |
Update this Server’s Schema (NetWare 5 versions) |
Request the schema from the server holding the master replica of the root partition of the tree. |
Update all version 4.0x Server’s Schema (NetWare 4 versions) |
Update the schema on all servers in the tree for versions 4.0, 4.01, and 4.02. |
Declare a New Epoch |
Cause the server holding the master replica of the root partition to place new time stamps on all schema objects and declare a new epoch. This option requires the –A option. This option can cause more problems than it solves. Choosing a bad copy will cause severe damage because this option pushes changes out to all servers. |
Request Schema from Tree |
Request the schema to synchronize from the server with the master replica of the tree. If the server cannot connect to the master replica of [Root], it uses another replica. |
|
|
Troubleshoot and Solve Partition and Replica Consistency Issues
The Replica List
The replica list is stored in the partition root object as the Replica attribute. All replicas, including subordinate references, contain a copy of the Replica attribute. The following type of information is stored in the Replica attribute:
Server Name |
The name of a server holding a replica |
Type |
The type of replica being stored on a server |
State |
Denotes what it thinks the current state of the replica is |
Referral |
Information on how to connect to the server holding the replica |
Replica Number |
|
Transitive Synchronization Process
The transitive synchronization process provides convergence of data without requiring an eDirectory agent with changes to directly contact and synchronize those changes with every other agent in the replica ring. To accomplish convergence, transitive synchronization performs the following steps:
- The replica synchronization process is scheduled
When a change is made to a property of an object, the replica synchronization process is scheduled to run. When the process actually takes place depends on the type of change that was made. Two timers determine when the synchronization process runs:
Some changes, such as a change in a user’s password or access rights, need to be sent immediately to the other replicas. When these high-convergence attributes are modified, the replica synchronization process is scheduled with the fast synchronization interval of 10 seconds.
Less critical changes, such as a user’s last login time, can be collected locally for a short period of time before being sent to other replicas. The heartbeat triggers a scheduled synchronization at least every 60 minutes.
- The transitive synchronization process determines which replicas need to be synchronized
The Transitive Vector is a multivalued attribute of the partition root object. It is a group of modification time stamps that represent the values held by each replica. There is 1 transitive vector attribute for each replica in the ring.
By comparing time stamps in the Transitive Vector attribute, eDirectory can determine which replicas need to be synchronized.
- The source server initiates replica synchronization
Once a server determines that it must update a remote replica, it initiaties replica synchronization communications with the destination server.
- The destination replica sends its LRUT
The first action a destination server takes when replica synchronization from a source server begins is to send the source server its Local Received Up To (LRUT) attribute. An LRUT attribute is a non-synchronizing single-valued attribute whose value represents when and what changes have been received from other replicas.
- The source server verifies that synchronization is needed
When the source server receives the LRUT from the destination server, it compares the LRUT to its Transitive Vector attribute. Before sending any changes to the destination, the source server verifies that the destination server has not received the latest changes. By comparing the destination server’s LRUT to its Transitive Vector, the source server guarantees that the destination server truly needs to be synchronized. It may not be necessary to synchronize the destination server if it has already been updated transitively through an intermediary server. If the destination server has already been synchronized transitively, the source server updates its Transitive Vector and the synchronization process is finished.
- Updates are sent from the source server to the target server
After determining which servers hold replicas that need to be synchronized, the updates are sent.
- The source server updates its Transitive Vector
Once the source server has synchronized its updates, it updates its Transitive Vector to reflect the latest synchronization on the target server.
- The Transitive Vector is sent from the source server to the target server
The source server sends the target server its Transitive Vector values.
- The Transitive Vector is updated on the target server
When the source server sends its Transitive Vector values, the target server merges into its Transitive Vector attribute.
Replica Transition States
The transition states of the replicas are described in the following table:
State |
Description |
[0]: On |
Replica is not currently participating in any partition or replica operations. |
[1]: New Replica |
Begins operation of adding itself to the replica list. Server receiving new replica establishes communication with the server holding the master replica. The new replica is assigned a replica time stamp and is set to a state of New Replica. The synchronization process begins copying the partition contents to this server while updating the replica lists of the other servers in the replica ring. During this step, the server accepts information only from the master replica; clients cannot access this server’s new replica information until the process is complete. After the synchronization process has updated this server with the needed information, the server holding the master replica propagates a state change to Transition On for this server’s replica. The other servers in the replica ring are notified and set to Transition On as well. The server with the new replica must contact all other servers in the ring to change to Transition On. If a server is not contacted, that server will stay in a New Replica state. Before the replicas are changed to Transition On, any needed subordinate reference replicas are added to the servers and turned on. |
[2]: Dying Replica |
A request has been made to remove this replica. Once the changes have propogated it will either become an external reference (if it has a parent) and the state changed to On, or the state will become Dead. |
[3]: Locked |
Some partition operations require replicas to be locked for exclusive use (such as Move State 0). |
[4]: Change Replica Type State 0 |
If the change is to a non-master then the change is made and propagated to other servers in the replica ring. If changing a replica to master then a request is made to the server who is currently master and the master replica sets itself to ‘Change Replica Type State 0’ and propagates this to the other servers in the replica ring. Then the current master tells the new server that it is now master. The new master waits until its clock is ahead of the time stamps issued by the old master, then places new time stamps on all replicas for that partition. The new master then makes the state change to ‘Change Replica Type State 1’ |
[5]: Change Replica Type State 1 |
After the old master switches into this state it appoints itself as a secondary (read/write) replica. This change is propagated to all the partition’s replicas. After all the changes are received and updated, the state is changed to On, which is also propagated. |
[6]: Transition On |
Indicates that the replica has recently been added to the server using the Add Replica partition operation. |
[7]: Dead Replica |
Indicates that other servers are being notified that a replica is dying. After going though replica state 2 (Dying Replica) there still may be servers that need to be notified that the replica is going away. The replica stays in this state until the server holding the replica synchronizes successfully to another server, letting it know that the replica is ready to be removed. |
[8]: Begin Add |
Indicates that a replica is being added. This is the initial state that beings the process of adding a new replica. |
[11]: Master Start |
Indicates that the replica type is being changed. |
[12]: Master Done |
Indicates that the servers involved in the change of the replica types have been updated and the replica’s next state is On. |
[48]: Split State 0 |
This state occurs when a new partition is created or split from an existing partition. A request to create a partition is made to the server holding the master replica of the partition that is to be split. The master sets its state to Split State 0 and then communicates with the rest of the servers in the replica ring to inform them of the request. The master then sets all the partition’s replica to Split State 1. |
[49]: Split State 1 |
When in Split State 1, the server holding the master replica of the parent partition makes sure that all updates and synchronization are complete. If they are, the master turns on the parent partition and the new partition. This change is propagated to the other replicas. |
[64]: Join State 0 |
This is the state when 2 partitions are combined (joined) into 1. A request is sent to the server holding the master of the child partition. The child master locates the parent’s master replica and sends a request to be joined to the parent. The parent master sets the state to Join State 0 and propagates it to the partition’s replicas. The child master does the same for its partition’s replicas. Both servers then check to see if any servers need each other’s replica information. Servers that do not have both the child and parent partition get a copy of the replica. This sets the replica state to Join State 1. |
[65]: Join State 1 |
After the process of combining partitions has begun the next step is to erase the boundary between the partitions. This is what occurs in Join State 1. All object entries in both partitions are put into 1 partition. The new replica that was created is now in Join State 2. |
[66]: Join State 2 |
Join State 2 propagates the changes of the combined partition. The replica state then turns On. When its state is On, the parent master is the master replica of the new partition and the child master becomes a read/write replica. |
[80]: Move State 0 |
NDS allows any subtree to be moved as long as it has no child partitions and has consistent chema rules. The client sends a move request to the destination server (the server holding the master replica of the parent partition under which the childis moving). Rights are checked and the move begins. There is a time expectation set in the server’s memory. If the expected time does not expire, the move continues until finished; otherwise, time expires and the move is aborted. If time does not expire, the finished move request is sent to the source server (the server holding the master replica of the partition being moved). The source server identifies the destination server and sends it the object entries in the partition. The destination server checks to make sure all servers in the desination’s backlinks will support the move. If all is okay, the destination server initiates the move and sets the partition’s replica state to Move State 0. The source server does the same with its replicas. The propagation begins and the changes are sent to all replicas. The source server sends a request to lock the source server’s replica (since it is the master replica). The changes are then made and the external references and backlinks are created accordingly. After all entries have been moved and been synchronized successfully, the replica is unlocked and turned on. |
[81]: Move State 1 |
Move subtree, which relocates a partition from its existing parent partition to a different partition. |
[82]: Move State 2 |
Move subtree, which relocates a partition from its existing parent partition to a different partition. |
Receive Updates from the Master Replica
This operation forces the replica on the selected server to receive all objects from the master replica of the partition. Perform this operation if a replica becomes corrupted or has nit received updated data for an extended period of time. The replica’s current data will be overwritten with the data from the master replica, which is assumed to be the most current and accurate copy of the partition.
Advantages |
Disadvantages |
Ensures the selected partition synchronizes with the master replica. |
Modification made to the selected server’s replica that have not been synchronized to the master replica are lost. |
Generates less network traffic than doing a Send All operation. |
Does not work on the server holding the master replica. |
Send Updates from a Replica
Shen you send updates from a replica, the Directory objects in that replica are sent from the server the replica resides on to all other replicas of the partition, including the master replica. These other replicas combine the new objects sent with the objects they already have. If the other replicas have data in addition to the data sent to them, they retain that data. This operation lets you manually synchronize Directory objects of replicas if any replicas get out of sync.
Advantages |
Disadvantages |
Ensures a replica synchronizes with all other replicas of the partition. |
Can create high network traffic. |
Is non-destructive: the information sent to other replicas is added to what exists on that replica. |
|
Unknown Objects
Unknown objects are represented graphically in 2 ways. The first is a yellow circle around a question mark, this requires intervention from the network administrator. The second is represented as a white circle around a question mark and is more correctly referred to as an unmanageable object, this usually occurs when the version of ConsoleOne you are running does not have the appropriate snap-in installed to manage that object.
There are 5 common unknown object types:
- Missing Mandatory Attribute
- Unknown Forward Reference
- Unknown External Reference
- Non-Auxiliary Class Compatible Replica
- Deleted Object
Missing Mandatory Attribute
Each type of eDirectory object is called an object class. Each class of object requires certain properties or attributes. If an attribute is mandatory, a value must be assigned to the attribute before an instance of the object can be created. You can fix them by taking 1 of 3 actions:
Re-send the object from a replica that has all the object’s attributes. This oprtion works well if there are only a few objects that are unknown.
Replace the replica that has the unknown objects with an uncorrupted replica from another server. This is usually the best solution. You can achieve this in several ways:
- Delete the corrupted replica and then place a replica back on the server.
- Have the corrupted replica receive all objects from the master replica, if the master replica is not corrupted. Use DSREPAIR, in Advanced Options Menu/Replica and Partition Operations/View Replica Rings, select the server where the replica is corrupted and choose Receive All Objects from the Master to this Replica.
- Use DSREPAIR to send all objects from a replica that is not corrupted to every replica in the ring. Use DSREPAIR, in Advanced Options Menu/Replica and Partition Operations/View Replica Rings, select a server holding a replica that is not corrupt and choose Send All Objects to Every Replica in the Ring.
- Delete the unknown objects. This option works best for object types that are easily re-created.
Unknown Forward Reference
A forward reference object is a placeholder created for non-existent containers until the real object is created (during an import). When a later operation creates the container, the forward reference is changed into a normal entry. To fix:
- These occur as part of the normal replica synchronization process and will become known when the actual object successfully synchronizes. If it does not, you should verify that the LDIF file has a command to create the parent container.
- Check for and resolve any schema and object synchronization problems, and then wait for the synchronization to finish.
- In rare cases you may need to use the Single Object Send operation to send the entry from a consistent replica to all other replicas.
Unknown External Reference
An external reference object that has not yet been backlinked, or the real object is unknown. To fix:
- Check and resolve any errors reported in the Agent Process Status in the External Reference section.
- Start the Reference Check background process and wait for it to complete.
Non-Auxiliary Class Compatible Replica
Auxiliary classes are supported in eDirectory but not in NDS. A replica on a non-auxiliary class compatible NDS server will show objects with auxiliary classes as unknown objects. To determine if the replica resides on a server that supports auxiliary classes:
- Check the version of the server
- Check the version of the Directory service
- In iMonitor, examine the AuxClass Object Class Backup, auxClassCompatibility, and Object Class attributes.
Deleted Object
An object may appear as unknown if it is still in the process of being deleted. You can identify if an object is still being deleted by the following:
- Entry Information Flags attribute value doesn’t show Present
- There may be obituary attributes on the object
- These objects are visible in utilities such as iMonitor
|
